[レポート] Bigtable を使いこなす！KARTE で秒間 13 万イベントを 0.x 秒以内に捌く秘訣 #GoogleCloudDay

こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。

「Google Cloud Day: Digital ’22」が2022年4月19日~21日に開催されました。
本ブログはイベント内のセッション「Bigtable を使いこなす！KARTE で秒間 13 万イベントを 0.x 秒以内に捌く秘訣」のレポートブログです。

セッション概要

概要

より高速により多くのイベントを捌くため、KARTE の解析基盤をリアーキテクチャしました。 現在移行途中ではありますが、リアルタイム解析速度が 20 % 以上向上し、かつシステムコストも 10 % 以上削減することができました。 リアーキテクチャでは、既存 Bigtable のスキーマの再設計や新しい Bigtable の使い方に挑戦するなど、 Bigtable をフル活用しています。 今回はその具体的な方法をご紹介します。

取り上げる主な Google Cloud 製品 / サービス

• Cloud Bigtable
• Cloud Pub/Sub

スピーカー

株式会社プレイド 日鼻 旬 さま

KARTEとは？

• 顧客体験を改善するためのサービス
• Web サイトに訪れたエンドユーザーの行動をイベントとしてリアルタイムに解析
• クライアントが解析結果をもとに、ユーザーひとりひとりにカスタマイズした体験を適用できるようになっている
  • 初めてサービスを訪れたユーザーにガイドを出す
  • 新着アイテムを見ているユーザーにレコメンドを出す etc...
• 規模

リアルタイム解析基盤とは？

• クライアントが、いつ誰に何を配信するのかという Action を呼ばれる設定を事前に行う
• エンドユーザーがクライアントサイドに来たときに、イベントが KARTE のサーバーに送信される
• イベントをもとに、いつ誰に Action を配信すべきかの判定を行い、実行する
• これまでのイベントをユーザーデータに格納していてそのデータをもとに次の Action を実行できる

アーキテクチャ上のポイント

• 事前にユーザーデータを格納した Bigtable からデータを読み込んでイベントをもとに最新化して Action の判定をする
• 更新はバックグラウンドで Redis のイベントキューを通じて複数のイベントを一気に計算してユーザーデータに書き込むようにしている

なぜ Cloud Bigtableなのか

• サービスに耐えられる高スケーラビリティ
  • 累計145億ユーザー
  • 全データ量 450TB
• 低レイテンシー
• 低コスト

現基盤での課題と対策

課題

• これ以上大幅なパフォーマンス改善が見込めない
• 結果整合性
  • 更新処理待ちのデータがユーザーデータに加味されない時があった
• ボトルネックはユーザーデータの Read 処理

対策

• ゼロからアーキテクチャを見直すことにした

• Cloud Bigtable （ユーザーデータ）のスキーマ再設計

• Cloud Bigtable を Queue として使い、強整合性を実現した

新解析基盤での Cloud Bigtable フル活用方法

Before

• 各期間ごとに1行ごとにデータを格納していた

After

• 複数の期間を1行にまとめるスキーマ設計に変更した

スキーマ変更による効果・副作用

• Read 速度向上
• コスト削減
  • Cloud Bigtable の CPU 使用率が低下した
• ホットスポット増加
  • 一行あたりのデータサイズ増加により大量アクセス時に過負荷状態が引き起こされた
  • アプリケーション側で大量アクセスの対策を実施した

強整合性の実現（ Cloud Bigtable as a Queue ）

• なぜ最初からこの構成にしなかったか
  • イベントの発生順序を担保した上で低レイテンシーを維持するのが一番の課題だった
• なぜ Cloud Bigtable を Queue として使うのか？
  • 既存の Queue 用のサービスでは低レイテンシーと高スケーラビリティや可用性の両立が難しかった
  • Cloud Bigtable は求めている機能において全体のバランスがよかった
• イベントキュー用の Cloud Bigtable スキーマ設計
  • Write / Read ともにパフォーマンスは問題なかった
  • 現状、順序の維持の問題から単一クラスター構成を取っている
    • 可用性の向上については検討中

今後の展望

• パフォーマンス10倍・コスト10分の1を目指している
• 新解析基盤への完全移行
• Cloud Bigtable だけではなく他のサービスも適材適所で使い倒していく

Q&A（抜粋）

Q. 新解析基盤について Cloud Spanner を利用する予定はあるか
A. 候補にはあがっている。適用に対してのメリットは可用性と強整合が満たせるところ。低レイテンシーとコストは Cloud Bigtable が勝っているのでトレードオフとなる点を考慮しながら検討したい。

Q. 新解析基盤の移行の状況について
A. 移行は90パーセント程度完了していて、低レイテンシの実現、パフォーマンスが向上した。ユーザーデータのアクセス頻度を効率化することで半分程度のリソースで運用できる状態になり、コスト低下の余地もできている。

Q. Cloud Datastore が候補にあがらなかった理由は？
A. ユーザー数が多く大量のデータ量が入ってくるというところで高スケーラビリティのサービスが候補になった。複雑なクエリを書きたいわけではなかったのも候補にあがらなかった理由。

Q. Firestore ( Datastore モード ) と Bigtableの使い分けは？
A. ペタバイト級のデータを持てること、低レイテンシー、高スループットでコスト面の有利さも考えると Bigtable にかなうものはないと思っている。

Firestore は完全にサーバーレスなところが特徴。Bigtable も運用自体はほぼ自動化されているが、Firestore はクラスターの管理も含めて全く意識せず、データの格納に特化した使い方ができる。
また、Firestore は Document DB なので比較的大きい JSON ドキュメントを格納したいユースケース等に向いている。

Q. Firestore と Datastore の使いわけ（比較）は？
A. Firestore は Firebase （ mobile Backend as a Service ）と密接に統合されているので、モバイルアプリケーションを簡潔に、サーバーレスに作りたいというユースケースだと有利に働く

感想

低レイテンシーで高スループット、かつ高い可用性と整合性のバランスなどさまざまな条件の中で、実現のために工夫されている点が興味深かったです。
サービスごとに得意・不得意の特性があり、トレードオフが発生する中で一番何を実現したいのかを考えながら技術選定する姿勢がとても大事だと感じました。

アーカイブが公開されていますので、気になった方は視聴してみてはいかがでしょうか。

以上、CX事業本部MAD事業部のYui(@MayForBlue)でした。